Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

34장. ALB의 라우팅 — 리스너 · 규칙 · 타깃 그룹

이 장에서 말하고자 하는 것

앞 장에서 우리는 ELB 세 종류를 보고
HTTP 서비스에서는 ALB가 기본 선택임을 정리했다.

이제 ALB 안으로 들어간다.

ALB가 트래픽을 어떻게 받아
어디로 보내는지를 결정하는 세 부품이 있다.

리스너 (Listener)
   ↓
규칙 (Rule)
   ↓
타깃 그룹 (Target Group)
   ↓
실제 서버

이 셋의 관계를 이해하면 ALB의 모든 동작이 한눈에 들어온다.

1. 큰 그림 먼저

[ALB]
 ├─ Listener (443 HTTPS)
 │   ├─ Rule 1: path = /api/*       → TG-api
 │   ├─ Rule 2: host = admin.…      → TG-admin
 │   └─ default                     → TG-web
 │
 ├─ Target Group "TG-api"   ─→ [api-task-1, api-task-2]
 ├─ Target Group "TG-admin" ─→ [admin-task-1, admin-task-2]
 └─ Target Group "TG-web"   ─→ [web-task-1, web-task-2]

이 한 장에 모든 게 들어 있다.

2. 리스너 — 어떤 포트로 받을 것인가

리스너는

어떤 포트 · 어떤 프로토콜로 트래픽을 받는다

의 선언이다.

흔히 두 개를 만든다.

Listener 80  (HTTP)  → 443으로 리다이렉트
Listener 443 (HTTPS) → 실제 라우팅 규칙

HTTPS 리스너에는 ACM 인증서가 붙는다.

3. 규칙 — 어떤 조건에 어디로 보낼 것인가

리스너 안에 여러 규칙(Rule) 을 둘 수 있다.

규칙은 다음 정보로 매칭한다.

  • 경로 (/api/*)
  • 호스트 (admin.example.com)
  • HTTP 헤더
  • HTTP 메서드 (GET/POST)
  • 쿼리 스트링
  • 소스 IP
규칙 1: 경로가 /api/* 이면     → TG-api
규칙 2: 호스트가 admin.… 이면  → TG-admin
기본:   그 외 전부             → TG-web

규칙은 우선순위 순으로 평가되고
가장 먼저 매칭된 규칙이 적용된다.

4. 타깃 그룹 — 실제 서버들의 모임

타깃 그룹(Target Group)은

같은 역할을 하는 서버들의 묶음

이다.

TG-api
   ├─ task 1 (10.0.1.10:8080)
   ├─ task 2 (10.0.2.11:8080)
   └─ task 3 (10.0.3.12:8080)

타깃은 다음 세 종류가 될 수 있다.

  • EC2 인스턴스
  • IP 주소 (ECS Fargate가 여기 해당)
  • Lambda 함수

ECS / Fargate 환경에서는 IP 타입 타깃 그룹 을 쓴다.

5. 헬스 체크 — 누가 살아 있는가

타깃 그룹마다 헬스 체크 규칙이 있다.

경로:      /health
프로토콜:   HTTP
간격:      30초
정상 응답:  200 OK
연속 정상:  2번 → 살아 있음
연속 실패:  2번 → 죽음으로 표시

ALB는 살아 있는 타깃에만 트래픽을 보낸다.

새 컨테이너가 떠도 헬스 체크를 통과해야 트래픽이 들어간다
그래서 /health 엔드포인트는 모든 서비스에 필수다

6. 분배 알고리즘

ALB가 여러 타깃 사이에 트래픽을 어떻게 나누는가.

기본은 Round Robin 이다.

요청 1 → task 1
요청 2 → task 2
요청 3 → task 3
요청 4 → task 1
...

특정 사용자를 같은 서버에 계속 보내고 싶다면
Sticky Session(고정 세션) 을 켠다.

사용자 A (쿠키) → 항상 task 2

다만 가능한 한 무상태로 만들고 sticky를 켜지 않는 게
확장과 장애 대응에 유리하다.

7. 우리 서비스에서

척추 그림에서 ALB 안쪽 모양은 이렇다.

[ALB]
 ├─ Listener 443
 │   ├─ /api/orders/*    → TG-orders
 │   ├─ /api/users/*     → TG-users
 │   ├─ /api/payments/*  → TG-payments
 │   └─ default           → TG-web
 │
 ├─ TG-orders   → ECS "orders"   (2 task)
 ├─ TG-users    → ECS "users"    (2 task)
 ├─ TG-payments → ECS "payments" (2 task)
 └─ TG-web      → ECS "web"      (2 task)

ALB 한 대 안에서
경로만으로 4개의 마이크로서비스를 나눠 보낸다.

이게 다음 장에서 본격적으로 다룰 주제다.

8. 직접 확인해보기 — CLI

리스너 보기

aws elbv2 describe-listeners \
  --load-balancer-arn <alb-arn>

리스너 안의 규칙 보기

aws elbv2 describe-rules \
  --listener-arn <listener-arn>

타깃 헬스 상태 확인

aws elbv2 describe-target-health \
  --target-group-arn <tg-arn>

이 명령은 운영 중 가장 자주 쓴다.

“트래픽이 왜 우리 서비스로 안 와요?” → 80%는 헬스 체크 실패

9. 코드로는 이렇게 생겼다 — Terraform

타깃 그룹 · 리스너 · 규칙을 한 묶음으로 만든 모양이다.

# 타깃 그룹
resource "aws_lb_target_group" "api" {
  name        = "tg-api"
  port        = 8080
  protocol    = "HTTP"
  target_type = "ip"            # Fargate 를 위해 IP 타입
  vpc_id      = aws_vpc.main.id

  health_check {
    path                = "/health"
    interval            = 30
    healthy_threshold   = 2
    unhealthy_threshold = 2
  }
}

# 443 리스너
resource "aws_lb_listener" "https" {
  load_balancer_arn = aws_lb.main.arn
  port              = 443
  protocol          = "HTTPS"
  certificate_arn   = aws_acm_certificate.main.arn
  ssl_policy        = "ELBSecurityPolicy-TLS13-1-2-2021-06"

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.web.arn
  }
}

# /api/* 경로 규칙
resource "aws_lb_listener_rule" "api" {
  listener_arn = aws_lb_listener.https.arn
  priority     = 100

  condition {
    path_pattern {
      values = ["/api/*"]
    }
  }

  action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.api.arn
  }
}

세 리소스가 한 단위로 동작한다는 점만 기억하면 된다.

10. 이렇게 쓰면 망한다 — 안티패턴

안티패턴 1. /health 엔드포인트를 인증 뒤에 둔다

GET /health → 401 Unauthorized

ALB는 401을 실패로 본다 → 타깃이 영원히 죽음 상태.

/health 는 인증 없이 200을 돌려준다

안티패턴 2. 헬스 체크 경로를 무겁게 만든다

/health → DB 쿼리 5개 → 외부 API 호출

헬스 체크 자체가 시스템을 무겁게 만든다.

/health 는 빠른 응답만 한다
깊은 검사는 별도 /ready 등으로 분리

안티패턴 3. 모든 서비스를 하나의 타깃 그룹에 몰아넣는다

TG-everything → orders · users · payments · web 모두
  • 한 서비스 장애가 헬스 체크에 섞인다
  • 스케일링이 같이 묶인다
  • 배포가 분리되지 않는다

서비스별로 타깃 그룹을 분리한다

안티패턴 4. Sticky Session을 기본으로 켠다

확장하기 어렵고 장애 대응이 늦어진다.

가능한 한 무상태로 만들고 sticky는 마지막 수단

11. 한 줄로 정리

ALB는 리스너 · 규칙 · 타깃 그룹의 세 부품으로 트래픽을 받아 분배한다

12. 이 장의 핵심 정리

  1. ALB는 리스너 · 규칙 · 타깃 그룹의 3단 구조다.
  2. 리스너는 어떤 포트로 받을지를 정한다.
  3. 규칙은 경로 · 호스트 등의 조건으로 어디로 보낼지 결정한다.
  4. 타깃 그룹은 같은 역할의 서버들을 묶고, 헬스 체크로 살아 있는 곳에만 보낸다.
  5. ECS / Fargate에서는 IP 타입 타깃 그룹을 쓴다.
  6. /health 는 인증 없이, 가볍게, 항상 빠르게 응답해야 한다.